Behavior Driven Development (BDD) specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit. The desired behavior is derived from the requirements set by the business—that is, the desired behavior that has business value for whatever entity commissioned the software unit under construction. FIG. 1A illustrates the position of BDD within the pyramid of software testing.
BDD tests are typically written using Gherkin. In Gherkin, each test is referred to as a “scenario” and each scenario includes a “given” step which refers to an initial program state, a “when” step defining an action, and a “then” step indicating the desired outcome. Each of the steps are then parsed with a parser and the appropriate testing script is executed. As Gherkin is typically written in a plain language targeted to business and other non-technical users, it allows for high level design and generation of BDD testing.
Functional testing refers to the process of verifying that a piece of software is conforms to end-user or business goals. Typically, functional testing involves evaluating and comparing each software function with the business requirements. Software is tested by providing it with some related input so that the output can be evaluated to see how it conforms, relates or varies compared to its base requirements. Moreover, functional testing also checks the software for usability, such as by ensuring that the navigational functions are working as required.
As shown in FIG. 1B, functional testing occurs after BDD testing and has historically been a manual effort. These validation tests are written in an industry standard test case format which is significantly more details then BDD testing. Positive and Negative scenarios are included and each step is verified.
As discussed earlier, Gherkin is utilized for higher level BDD tests. However, there are several difficulties with using Gherkin to write functional tests. As functional tests require verification of steps on a more granular level than BDD tests, writing functional tests with Gherkin can be verbose, since adding additional given/when/then steps are required. Additionally, the process of generating the Gherkin code can be time consuming, as Gherkin bears little resemblance to the industry standard functional test formats. Furthermore, while short Gherkin tests are useful for BDD testing with simple requirements, Gherkin cannot be used for functional testing which typically requires many different parameters. Since each of the steps in Gherkin must be separately parsed by a parser, a complicated parser would be required to handle the requirements of functional tests. Additionally, the step of parsing a free-form text file produces overhead in the form of computing inefficiencies and can be error-prone, raising implementation time and cost while lowering execution speed and computing efficiency.